feat(core): configure model reasoning capabilities - #10999

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

Thanks for the PR — the write-up and the design doc are unusually clear about intent, which made this easy to follow.

Template looks good ✓ (all required headings present, Tested-on filled in, Chinese section included).

Problem: this is a feat, so no reproduction is expected, and the UX observation behind it is real — today /effort on deepseek-v4-pro offers low/medium/xhigh, which that model does not accept. But the framing that reasoning support currently requires "another model-name or hostname branch spread across clients and request adapters" does not match what is on main. A declarative, per-model contract already exists in the provider adapter layer:

• supportedReasoningEffortsFor(model) on OpenAICompatibleProvider — its docstring is literally "Effort tiers this endpoint accepts for model. Override in a subclass whose endpoint takes max". deepseek.ts and zai.ts already override it, and DashScope declares DASHSCOPE_TIERED_EFFORTS.
• clampConfiguredReasoningEffort() caps the pipeline-injected tier through clampReasoningEffort(requested, supported) in core/reasoning-effort.ts, whose header says the ladder exists "so a new provider only needs to declare its supported subset".
• translateReasoningEffort() in deepseek.ts already flattens nested reasoning.effort onto top-level reasoning_effort, including xhigh → max, and the pipeline already emits thinking: { type: 'disabled' } for DeepSeek hosts.
• Config.setReasoningEffort's own docstring states the invariant: "Provider adapters clamp the tier to what the active model supports."

So the question this PR raises is not "should models declare their reasoning capability" (they should) but where that declaration lives: in the provider preset / model registry (this PR), or in the provider adapter (today). After this PR both mechanisms are live at once, and they disagree.

Direction: escalating to a maintainer. This touches model selection, adds a new user-editable settings contract (modelProviders[].capabilities.reasoning), and changes the shape of the ACP reasoning_effort session-config option (option list + _meta keys). Those are the areas where the gate does not get to decide architecture on its own. Relatedly, the core change is 105 production lines inside packages/core/src/{models,providers,core}, which puts it under the 100%-confidence bar for core — and I am not at 100%, for the concrete reasons below.

Size: 534 changed lines total → 368 production (core 105, cli 263), 126 test, 40 docs (the design doc). feat-type touching core, so no size block; below both the 500-line maintainer-awareness and the 1000-line split thresholds. Breadth is 18 files across two packages, which is a threading cost rather than a red flag on its own.

Approach — what I'd want answered before this goes further. I skimmed the code closely enough to have opinions, so here they are as questions rather than as a block:

• Ordering: the new flattening runs before the adapter clamp, and it drops tiers the clamp would have mapped. applyConfiguredReasoningEffort is applied to baseRequest in buildRequest, i.e. before this.config.provider.buildRequest(...) at pipeline.ts:880. It destructures effort out of the nested reasoning object unconditionally and only promotes it to top-level when the tier is in the configured efforts list. For deepseek-v4-pro (efforts: ['high','max']), a stored xhigh therefore reaches the DeepSeek adapter with no nested effort → translateReasoningEffort no-ops → the request carries no reasoning_effort at all and DeepSeek falls back to its own default, where main today sends max. Same for low/medium, which the adapter maps to high. clampConfiguredReasoningEffort never sees the value — and its docstring says it exists precisely because "the tier is configured once (/effort) and persisted, so an unaccepted value is not a one-off rejection". /effort and the ACP path do reject out-of-list tiers now, but setReasoningEffort itself does not validate, and priorReasoningEffort is restored across auth/model switches (config.ts:4267, 5486, 5503), so a tier persisted before an upgrade is a live path. Routing the configured list through the existing clampReasoningEffort instead of dropping would keep the invariant and reuse code that is already tested.
• A partial capability in user settings crashes /effort. getReasoningEffortsForConfig returns reasoning.efforts when toggleOnly is falsy. modelProviders is not schema-validated (settingsSchema.ts:359 is a bare type: 'object'; validateModelConfig only checks id and the selector-only flags), so a hand-written capabilities: { reasoning: { thinking: true } } — no toggleOnly, no efforts — yields undefined from a function typed readonly ReasoningEffort[]. effort-command.ts then calls availableTiers.join(', ') and dialogs-modes.tsx spreads [...tiers], so every /effort invocation and the OpenTUI dialog render throw a TypeError. Since the design doc makes this a configuration-only surface users are meant to edit, a runtime guard (reasoning.efforts ?? []) seems worth having.
• canDisable?: false is read in four places and set by no producer — neither the DeepSeek preset nor any of the six static entries. It is inert today; is it needed now, or is it a knob for the deferred follow-up?
• disableField is required by the new core type but only read in the core pipeline (registry path). The six values added to the CLI's static MODEL_CONFIGURATIONS table are never read on that path — they exist to satisfy the shared type. Worth deciding whether the CLI's static table and the core registry should really share one wire-level type when only one of the two paths reaches the wire.
• The diff is wider than "only deepseek-v4-pro". Because disableField is mandatory, five existing toggle-only Qwen models changed too, and with them the TUI: /effort on e.g. qwen3.7-plus no longer opens a picker (it returns an info message), and /effort high now errors where it previously set the tier. That may well be the intended "Before" fix, but it is a user-visible narrowing on this product's primary models and it is not in Risk & Scope, which says "Breaking changes / migration notes: none".
• buildGenerateContentConfig's samplingParams early-return now merges buildReasoningConfig(request). That changes the wire for every model whose registry entry carries samplingParams — provider-config.ts:106 emits it from an advanced maxTokens config — not just DeepSeek. It looks like a genuine consistency fix (that branch used to drop a configured reasoning object entirely), but it deserves a line under Risk & Scope and ideally a test of its own.
• Layering: effort-command.ts, DialogManager.tsx and dialogs-modes.tsx now import from acp-integration/model-configuration.js. There is one precedent (modelCommand.ts), so this is a question, not a violation — but getReasoningEffortsForConfig reads like core material, next to clampReasoningEffort.

Risk: the revert-history screen matched four high-risk paths — acp-integration/acpAgent.ts, acp-integration/model-configuration.ts, acp-integration/session/Session.ts, and core/openaiContentGenerator/pipeline.ts. That is not a block, but it means full review depth and real CI evidence before anyone approves.

Testing: CI on the reviewed commit was still in flight when this ran — Test (ubuntu-latest, Node 22.x), Lint & Static, Serve A/B, Integration Tests (no-AK, No Sandbox), OpenTUI no-flicker gate, TUI parity snapshots, Real daemon E2E / Java 11 and Dependency CVE audit all in_progress, with Test (macos/windows) and Integration Tests (CLI, No Sandbox) skipped. So there is no test evidence to quote yet, and nothing here is verified by me — this pass is static reading only. Two things the diff cannot settle, if a maintainer wants them settled: @qwen-code /verify for the wire claims (top-level reasoning_effort: "max", thinking: { "type": "disabled" }, and specifically what a stored xhigh produces before vs after — the new pipeline test injects getResolvedModelConfig as a mock, so it passes whether the out-of-list tier is clamped or dropped), and @qwen-code /tmux for the two effort pickers.

Not moving on to code review as a separate stage: the direction question above is the thing to settle first, and I would rather hand it over with the concerns named than approve or reject around it. No approval and no request-changes from me — this needs a human call. I could not resolve an accountable owner deterministically (the PR carries no area label, there is no prior human reviewer, and no maintainer handle is configured), so no @mention: whoever owns model/provider config, this one is for you.

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 22f6cb11844e3e9d41eea32d7d63c0c42e6ecc90 · re-run with @qwen-code /triage}

🩺 serve daemon A/B

Built the PR base vs this PR head 22f6cb1, drove a fixed endpoint set against each, and diffed the JSON responses. Only fields that changed are shown.

✅ No response changes against the PR base across 12 scenario(s).

— Qwen Code · serve A/B